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REMARKS 

Claims claimsl, 3-13, 15-16, and 18-43 were previously pending in this application. No 
claims have been amended, added or delelted and accordingly claimsl, 3-13, 15-16, and 18-43 
remain pending for examination with claims 1, 10, 13, 15, 16 and 21 being independent claims. 
No new matter has been added. 

Re jections Under 35 U.S.C. §102 

The Office Action rejected claims 10-12, and 21-23 under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,546,005 (Berkley). This is the same rejection of the claims as 
was made in the September 15, 2005 Office Action. 

Independent claims 10 and 21 recite a database from which a provider of services can 
obtain a public code of an entity seeking services. In particular, the system and method of 
Applicant's invention as claimed in independent claims 10 and 21 is directed to a database where 
a service provider can go to obtain a public code identifying the participant to who the services 
are to be provided, which public code can be used to map to data required by the service provider 
in order to provide the services to the participant. 

With respect to independent claim 10, it recites, inter alia, a secure registry system that 
comprises a database from which a public code for each entity using the secure registry system 
may be obtained, and a processor at a provider of services that includes a mechanism for 
mapping the received public code to data required by the provider of services, and using the 
mapped data to perform the services. 

The Examiner in response to Applicants response to the September 15, 2005 Office 
Action argues that the term "public code" is not defined in the specification and therefore the 
interpretation of the public code in the claims, i.e., for example user identifier, user's name, 
meets the claim limitation. The applicant respectfully disagrees. 

The specification discloses, for example referring to FIG. 1 1 of the drawings at Paragraph 
[089] of the published application, that the member of the USR system provides an address code 
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on a public area of the USR database 24 that is available to all persons to see (1 100). This code 
may for example be six alpha characters, which should be adequate for currently anticipated 
system populations. 

The Examiner further argues that Berkeley teaches a database from which the public code 
(i.e., for example user identifier, user's name) for each entity may be obtained, and a processor at 
a provider of services for entities, including a mechanism for mapping each received public code 
to data required by the provider in order to provide the services. The applicant respectfully 
disagrees. 

Applicant's specification discloses that , for example referring to FIG. 1 1 of the drawings 
at Paragraphs [091-092] of the published application, that when someone wishes to have a parcel 
or other items delivered to the user, the sender retrieves the user's address code from the USR 
database 24 and prints the address code on the parcel (1 104). In addition, the specification 
discloses that the delivery service queries the USR database 24 for address information 
corresponding to the address code (1 106). The USR database 24 retrieves the appropriate address 
data and provides the address information to the delivery service. The delivery service either 
prints out an address label, prints a machine readable bar code to be attached to the package, or 
correlates an entry in a delivery database between the address code and the user address (1110). 
The delivery service then uses this retrieved information to deliver the package to the user while 
never supplying the merchant with the user's permanent or temporary address. A user may also 
automatically provide for address changes where the person moves by providing notice to the 
USR system. 

Berkley does not teach, disclose or suggest a database from which a provider of services 
can obtain a public code of an entity seeking such services. In contrast, Berkley merely teaches 
that a subscriber looking to contact a user of the AUR system contacts the AUR system of 
Berkley and enters a user identifier, such as the user's name, and initiates a search of the 
database for entries in the AUR database corresponding to the user, such as the fax number or a 
number to leave a voice mail for the user. In other words, Berkley discloses that the requesting 
or subscribing party knows the identifier information of the party for which it seeks information. 
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Berkley makes no provision for obtaining the public code of the user for which the requesting 
party is seeking to provide services from the AUR database, and thus makes no provision for the 
requesting party not knowing the public code of the entity. 

Since Berkley makes no provision for obtaining the public code of the user for which the 
requesting party is seeking to provide services from the AUR database, Berkley cannot teach, 
disclose or suggest a processor at a provider of services that includes a mechanism for mapping 
the received public code from such AUR database to data required by the provider of services in 
order to provide such services, and using such mapped data to perform the services. In contrast, 
Berkley discloses that in response to a subscribing party providing identification information for 
a user (e.g. the user's name), the system provides contact information about the user to the 
subscriber. However, such contact information is not information that is determined from a 
public code provided by the AUR database. 

Berkley et al. discloses an Active User Registry (AUR) that includes a database which 
contains a data structure of the ways in which one or more users can be reached via some type of 
communication network (e.g., POTS network or a packet network). The AUR has a feature that 
allows for brokering between a subscriber's request for communications contact information 
corresponding to a user and the user's preference of being reached by various communications 
alternatives. For a typical user, the entries in the AUR database 174 might include the following: 

Username; UserAliasl; UserAlias2:...,HomePhonel; HomePhone2; WorkPhone; 
WorkSecretary; Cellular-Phone 1; VideoPhone;...; WorkVoiceMessages; 
HomeAnsweringMachine; VideoMailMessages; BeeperNumberl;...; Email 1 ; Email2;...; 
WorkFAXl; WorkFAX2; HomeFAX;...; LAN IP; ModemlP;...; URL1; URL2;...; 
Multimedial; Multimedia2;...; ReachNumber. 

The AUR database consists of a series of user records, each user record containing one or 
more of the entries listed above. One possible arrangement of the AUR database is shown in 
FIG. 2. With references to FIG. 2, the AUR database as depicted consists of N user records, 
record 201 corresponding to user 1, record 202 corresponding to user 2, record 203 
corresponding to user 3, and so forth. Each user record in the AUR database contains entries for 
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the above-listed user communications contact information. Thus, as shown in the example of 
FIG. 2, record 201 corresponding to user 1 consists of a set of entries 210, 220, 230, 240, 250, 
260, 270, 280 and 290, each corresponding to a different category with each entry potentially 
consisting of one or more information data elements. 

The brokering process utilized by the AUR system is described with reference to FIGS. 
3A, 3B and 3C. In the example shown in FIG. 3 A, a non-family member subscriber attempting to 
contact the user at work prefers to leave a facsimile message for the user, as opposed to voice 
mail or other electronic message. The subscriber in this example initiates at step 301 a contact to 
the AUR system using multimedia PC 160 (shown in FIG. 1) by, e.g., using a modem to connect 
or to dial in to a site corresponding to AUR system 170 (shown in FIG. 1) or, alternatively, by 
sending a message to an IP address corresponding to the AUR system. The AUR system 
responds by presenting an access menu to the subscriber. Using a text-based search tool, the 
subscriber at step 302 enters a user identifier, such as information corresponding to the identity 
of the user (e.g., the user's name) and initiates, though the AUR system, a search of the AUR 
database for the user of interest to the subscriber. The subscriber at step 303 requests the AUR 
system to provide a communications number for sending a facsimile message for the user (this 
could be done, e.g., by typing the information in or by speaking into a microphone contained 
within the PC). The AUR system at step 304 compares the subscriber's request (facsimile 
message) against the user's preferred options (e-mail, voice mail or fax from a non-family 
member during the afternoon). The AUR system selects facsimile messaging (in this example, 
facsimile messaging is common to both user and subscriber preferences) and provides, at step 
305, a facsimile address for the user (e.g., WorkFaxl) to the subscriber. The subscriber then at 
step 306 initiates a communications contact with the user at the WorkFaxl address. 
Alternatively, the AUR system could ask the subscriber for a message or a filename of a 
document to be faxed and send it electronically to the user without the need to ever pass along 
the user's fax number to the subscriber. 

Similarly, in the example shown in FIG. 3B, the non-family member subscriber at step 
3 1 1 initiates a contact to the AUR system using telephone 1 50 (shown in FIG. 1) by, for 
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example, dialing a telephone number corresponding to AUR system 170 (such as, e.g., dialing 1- 
800-CALLATT and requesting the AUR system or alternatively, requesting the AUR cache). At 
step 312, the subscriber then enters a user identifier, such as username, by, e.g., speaking the 
name or pushing buttons on the telephone keypad corresponding to the letters of the user's name 
which initiates, through the AUR system, a search in the AUR database. By speech or by keypad, 
the subscriber enters a request for contacting the user by leaving a voice message at step 313. 
The AUR system at step 314 compares the subscriber's request (voice messaging) against the 
user's preferred options (e-mail, voice mail or fax from a non-family member during the 
afternoon) and, at step 315, returns the user's voice mail address (WorkVoiceMessages) to the 
subscriber (e.g., by speaking over the telephone the address obtained from the AUR database). 
Then at step 3 16 the subscriber initiates a communications contact using the appropriate 
communications number or address obtained from the AUR database, in this example, by dialing 
the telephone number corresponding to the user's voice mail (WorkVoiceMessages). 
Alternatively, the AUR system could ask the subscriber to record a voice message and then send 
it automatically to the user's WorkVoiceMessages address without the need to ever pass along 
the user's voice mail number to the subscriber. 

Accordingly, Berkley does not teach, disclose or suggest a database from which a 
provider of services can obtain a public code of an entity seeking such services and does not 
teach, disclose or suggest a processor at a provider of services that includes a mechanism for 
mapping the received public code from such AUR database to data required by the provider of 
services in order to provide such services. 

With respect to independent claim 21, independent claim 21 recites a database from 
which the public code for each entity may be obtained, and a processor receiving the public code 
and mapping the public code into data required by the provider of services in order to provide the 
services. Accordingly, independent claim 21 patentably distinguishes over Berkley et al. for at 
least the same reasons as discussed above with respect to independent claim 10, and withdrawal 
of this rejection is respectfully requested. 
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With respect to dependent claims 1 1 and 22 and 12 and 23, which depend from 
independent claims 10 and 21, respectively, each of these claims patentably distinguishes over 
Berkley for at least the same reasons as the independent claims 10 and 21, and therefore 
withdrawal of this rejection with respect to these claims is respectfully requested. 

Claims 13, 15 and 43 were rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent No. 6,941,271 (Soong). This is the same rejection of the claims as was made in the 
September 15, 2005 Office Action. 

The Examiner in response to Applicants response to the September 15, 2005 Office 
Action argues that the art on record teaches the claim limitations and therefore the rejection is 
maintained. The applicant notes that the Examiner has not responded to applicants prior 
response that points out that Soong is completely silent as a mechanism that generates a data 
request that includes a form in which such data is to be provided; and a response mechanism 
which collects data required by said form for a given request, and formats the collected data in 
said form. 

Independent claim 13 recites, inter alia, a secure registry system including a mechanism 
by which an organization desiring access to data in said database may gain such access, each said 
organization having a processor which generates data requests, each such data request including 
a form in which such data is to be provided; and a response mechanism which collects data 
required by said form for a given request, formats the collected data in said form, and sends the 
formatted data to the organization generating the request. 

Soong discloses a method for accessing patient records stored in a database, wherein the 
information is handled as records, and access rules as determined by the patient are stored in a 
computer. Upon access to the site computer 110, the site computer 1 10 provides a login ID web 
page 300 to the device 103 running a web browser application as shown in FIG. 3. The login ID 
web page 300 is a security measure to allow only authorized persons to access the site computer 
110. The site computer 1 10 checks the name and login ID of the individual against the database 
1 12 to ensure that the individual is allowed to have access to the database. The database 1 12 
includes the names and login IDs of all persons who are entitled to create or access health 
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records of the site computer 1 10. Furthermore, using the patient identity information provided by 
the individual, the site computer 110 checks to see that, even if the individual is permitted to 
enter the site computer 1 10 and access the database 1 12, the individual is entitled to create or 
access the health records of the particular patient identified. 

When the professional selects to create a record, the site computer 110 returns a record 
page 500 which prompts the professional to enter appropriate information about the condition of 
the patient as well as other kinds of information as shown in FIG. 5. A patient identity field 502, 
ID number field 504, date of visit field 506, treatment field 508, condition field 510, 
observations field 512, cost field 514, professional preparer field 516, and access code number 
field 518 prompt the professional to enter information. The preparer can enter this prompted 
information using any input method associated with the device 103. 

To ensure the privacy of the patient and limited access to the records of the patient, 
persons seeking records are allowed only to access and organize the selective portions of a 
patient's records, as shown in flow logic 700 of FIG. 7. At step 704, the site computer 110 
considers the provided login ID and name of the person seeking records access. The logic 
proceeds to a step 706 where the identity of the person is compared against one or more 
authorization databases. Each authorization database is programmable and lists names of persons 
entitled to access portions or entireties of the patient's records and also identifies which portions 
of the records are accessible by the person. The logic proceeds to a decision step 708 where the 
logic determines if the person is identified in an authorization database. If the result of decision 
step 708 is affirmative, the logic 700 proceeds to decision step 710 where the logic determines if 
the authorization database requires the person to have limited access to the records of the patient. 
If the result of decision step 710 is affirmative, the logic proceeds to a step 712 where the person 
is restricted in accordance with the authorization database to only portions of the patient's 
records. Other portions of the records are not accessible by that person. The logic proceeds to a 
step 714 where the logic ends. If the result of the decision step 710 is negative, the logic 
proceeds to a step 715 where the person has unrestricted access to the records and the logic 
proceeds to step 716 where the logic ends. If the result of decision step 708 is negative, the 
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person is not authorized to have any access to records, and the logic proceeds to a step 718 where 
the logic prevents the person from accessing the records. 

However, in contrast to the assertions of the Office Action, Soong is completely silent as 
to whether the requesting party can have a particular form that is to be populated with the data, 
such as a health form, that lists certain information to be provided, and that the methodology of 
Soong can gather the information that is solicited by the form. Soong does not teach, disclose or 
suggest a mechanism by which an organization desiring access to data in the database of the 
secure registry system comprises a processor which generates data requests, including a form in 
which such data is to be provided, and a response mechanism which, in response to such form, 
formats the collected data in that form and sends the formatted data in that form. Applicant has 
disclosed and recited that the form is, for example, a particular form which solicits particular 
data, such as a tax form, or a job application form, and the like. Applicant has also disclosed and 
claimed in other claims, that the data can be provided in various formats such as an e-mail or fax 
format . Accordingly, Applicant distinguishes between forms and formats. This rejection of 
claim 13 is improper and not adequately addressed by the Office Action. Accordingly, 
independent claim 13 is not anticipated by Soong and withdrawal of this rejection is respectfully 
requested. 

Independent claim 15 patentably distinguishes over the Soong reference for the same 
reasons as discussed above with respect to independent claim 13. In particular, Soong does not 
teach, disclose or suggest machine readable code which facilitates communication between a 
remote machine and a secure registry system, which is "configured to use the form in which the 
data is requested to select the data to be accessed, and to control the format in which the accessed 
data is to be provided to a remote machine." As has been discussed above with respect to 
independent claim 13, Soong is completely silent as to accessing data based upon a form to be 
completed or even providing the data in the format requested. Accordingly, independent claim 
15 is not anticipated by Soong and withdrawal of this rejection is respectfully requested. 
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Dependent claim 43 depends from independent claim 15 and accordingly is in condition 
for allowance for at least the same reasons as independent claim 15. Accordingly, withdrawal of 
this rejection with respect to these dependent claims is also respectfully requested. 

Re jections Under 35 U.S.C. $103 

The Office Action rejected claims 24-42 under 35 U.S.C. § 103(a) as being unpatentable 
over Berkley et al. (US 6,546,005) in view of U.S. Patent No. 5,915,023 (Bernstein). 

Without acceding to the appropriateness of the combination of Berkley et al. and 
Bernstein, Applicant specifically reserves the right to do so, the Applicant need not address the 
merits of each of the dependent claims 24-42 in view of this asserted combination of references. 
In view Applicant's discussion above that each of the independent claims 10 and 21 patently 
distinguishes over the Berkley reference, and in view of that the Bernstein reference does not 
cure the infirmities of the Berkley reference as to these independent claims, the asserted 
combination of references does not anticipate or render obvious the independent claims 10 and 
21. Therefore the asserted combination cannot anticipate or render obvious any of the dependent 
claims 24-42. Accordingly, withdrawal of this rejection is respectfully requested. 

Allowable Subject Matter 
Applicant notes that claims 1, 3-9, 16, 18 and 19-20 are allowed. 
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CONCLUSION 



In view of the foregoing amendments and remarks, reconsideration is respectfully 
requested. This application should now be in condition for allowance; a notice to this effect is 
respectfully requested. If the Examiner believes, after this amendment, that the application is not 
in condition for allowance, the Examiner is requested to call the Applicant's attorney at the 
telephone number listed below. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicant hereby requests any necessary extension of time. If there is a fee 
occasioned by this response, including an extension fee, that is not covered by an enclosed 
check, please charge any deficiency to Deposit Account No. 50/2762, Ref. No. W0537-7006. 



Respectfully submitted, 
Kenneth P. Weiss, Applicant 
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